			    TRAVELLER Digest 122

Topics covered in this issue include:

  1) BL rules changes/additions (long)	by merrick@RT66.com (Merrick Burkhardt)
  2) Re: Serendip Belt Forever!	by "Kelly St.Clair" <kstclair@CSOS.ORST.EDU>
  3) Unknown address	by wildcat.mail.room@jaguar.ac.edu (Wildcat Mail Room)
  4) Mapping Software Update	by Rob_Prior@nynet.nybe.north-york.on.ca (Rob Prior)
  5) Re: TRAVELLER digest 121	by Michael Llaneza <mllaneza@mercury.sfsu.edu>

----------------------------------------------------------------------

Date: Sun, 4 Dec 1994 11:38:26 -0700 (MST)
From: merrick@RT66.com (Merrick Burkhardt)
To: traveller@MPGN.COM (traveller)
Subject: BL rules changes/additions (long)
Message-ID: <9412041838.AA17045@RT66.com>


Howdy,

Here is the slightly cleaned up version of the new rules and additions I've done
for BL.  The guys I play with at the office, Lane Mogford, and Tom Kelly helped
a lot in playing, and play testing various rules changes.  Lane runs a CT 
campaign using the TNE stuff (mixed with CT stuff as needed).

Let me know what you think, I want to make these as bulletproof as possible.


Rules Changes for Brilliant Lances
**********************************

The Brilliant Lances rules work pretty well, but we have found a number of 
problems, and these are some of our attempts to correct them. The two major 
flaws are built around the general capabilities of the sensors, and the 
arbitrary nature of having tasks happen throughout the turn, but ranges and 
facings being sampled only at the endpoint of a ship's movement.  We now use 
simultaneous BR/Mayday movement all the time. 

The first problem to be addressed will be what I call Bogey Detection (BD).  
The BL rules state that "the crew may well be aware that 'something is out 
there' based on ghost images, etc.".  This is interesting, but it begs the 
question "When does my crew get the idea 'something is out there' in the
first place?".

For the purposes of playing BL (or using it in your role playing campaign) 
getting that first clue something is out there is a major point of tension. A 
ship's sensors are the players' window to their universe, so the sensor rules
need to be complete, and consistent.

One more digression before the substance of the post:  if you haven't read the 
box copy on the back of BL, do so.  If you have, read it again.  The feel of 
that copy is what I am after in these rules additions.  If you don't mind the

"Damn the passive sensors, light 'em up with the AEMS!" reality of the BL rules,
trash this post... I really want the use of active sensors to be a sober choice,
with both pros and cons (it's all pro now).  The point of this was to get that 
submarine feel back into passive sensing.  The Surprise rules I've added give
the sensor rules teeth, and make the whole thing work.  On to the meat...


Bogey Detection:
================
 
I will use the word Bogey in the same way that it is used in the BL rules.  A
Bogey is an indication of something odd, or even the presence of a ship, but 
there is not enough data for a firing solution.  Before a Bogey is detected the 
space around the ship in question looks empty.  These rules imply either some
degree of blind play with a ref, or trusting players.  We've used a system where
we abstract the closing moves out in the 80+ hex range and roll for the bogey
detections (easy to do since the range bands are *very* wide in the X times 
extreme range zone).

These rules can also be used simply to create plausible scenarios that don't
leave the players questions of "How'd he get so close without us seeing
him?", etc.unanswered. 

Sensor arrays are programmed to alert the operator when they find a region of
space that looks suspicious (ie. it could possibly be a target) under a set of 
predetermined conditions (what these conditions are is left to the players, and 
is a good place for PC sensor skill levels to be introduced).  The alert given 
*is* the Bogey Detection.

The Bogey Detection procedure is basically an extension of the existing rules
for Lock-Ons.  When preforming sensor tasks, each roll will have 2 difficulty
levels, an easier Bogey Detection task, and a harder Lock-On task.  If you make 
the Lock-On roll the Bogey Detection is moot (all Lock-Ons are also BDs... just 
very good ones)

Ranges for Bogey Detection work the same way as for Lock-On:  that is, double
short to get medium, double medium to get long, etc.. The only difference is 
that the maximum range for BD is 8 x Extreme range (64 x Short range).

The medium range for Lock-On is the range of Automatic Bogey Detection--within 
this range (providing there are no positive DiffMods!), if the sensors are 
working, and on, you will know something is in a hex (or, better put, that there
is nothing unnatural in the surrounding hexes). From there, double the range 
like all other ranges, and the Difficulty Level goes up normally for each range 
change(Easy, Ave, Diff, Form, Imp).

As an example, a sensor with a short range (SR) of 8 would look like this:

					RANGE 

		Short	Med.	Long	Extr.	2xExt	4xExt	8xExt	
Hexes:		8	16	32	64	128	256	512	1024	

Lock-on:		Ave	Diff	Form	Imp

Bogey:		Auto	Auto	Easy	Ave	Diff	Form	Imp  Prolonged
Rng(Mkm):	0.24 	0.48	0.96	1.92	3.84	7.68	15.36	


The body of the table is the base Difficulty Level for the given range for 
Lock-On and BD tasks.  

Note that this allows ships to maintain reasonable pickets so that they have a 
reason to go out and investigate/fight. Without this information, it is hard to 
rationalize any combat at all given the vastness of the areas to be patrolled
relative to the maximum Lock-On radius(draw a circle of maximum possible Lock-On
distance radius and compare it to the size of a star system :)

Also note that the BD task difficulty could be pushed to the left on the
chart, making auto BD only at the SR of the detector.


Procedure: 
During the Sensor phase of the turn, roll one D20 for each sensor used.  The 
same roll will be used for both Bogey Detection and Lock-On.  If the Lock-On is 
successful, Bogey Detection is assumed (and moot).  If the Lock-On task fails, 
the roll may still be good enough for a successful BD.  If Lock-On is not 
possible for the range in question, only Bogey Detection is possible.

DiffMods are allowed to push a Difficulty Level above Automatic (allowing, for 
example, terrain to protect a ship from Automatic detection).

All DiffLevel modifiers except Evasion apply to both bogey detection as well as 
Lock-On, Evasion has no effect on a Bogey Detection attempt (as it works by 
making the future position uncertain, not by hiding the target).

Note that Diff Mods for Lock-On apply to Bogey Detection, but not the other way 
around.  For example: a previous Lock-On gives a -1 DiffMod to both BD, and 
Lock-On attempts, but a previous BD gives a -1 DiffMod only to a BD task, not a 
Lock-On task.  This is also true of hand offs.

BDs can be lost just like Locks...  "Sir!  I saw something, but it just 
disappeared!"

You needn't have a BD first to achieve a Lock.

-------------------------------------
New Lock-On DMs

For Passive sensors, or DFs:
If the target goes active give a -4 DiffMod to the sensing ship if it's within 
twice the extreme range.  Lock-Ons can be made out to 2 x extreme range *only* 
if the target has had no BDs yet (this is Surprise, see below).  The task for

Locking at this range is IMP +2, and must be reduced by DMs to at least IMP to 
be attempted.  All of these ranges are using the ACTIVE sensors range bands (see
sensor rules changes below).
--------------------------------------

DiffMods for Bogey Detection Only:

For BD, if the target is within 8 times the extreme range of the *active* 
sensor, and goes active, it is automatically  marked as a Bogey to all ships 
with passive sensors within this range (see below for additions).  This auto BD
only applies to the turn the active is on.  Tech level differences between the 
sensors give DMs---use the DMs for TL vs Jammers (see senor rules below for 
clarification).

Weapons fire at the sensing ship during the previous turn by the target is a -1 
DiffMod for BD by passive sensors or DFs.

Lock-On hand offs, etc. all work normally. Bogey detections may be passed off
(to other sensors, or ships) just like Lock-Ons, but the DiffMods only apply to 
other Bogey Detection attempts.

Prolonged observation allows a ship to get a Bogey Detection at very distant 
points, but requires hours of observation to have an Impossible chance of a 
detection.  (I still need to finish these rules)


Results of Bogey Detection:

Success: 
 Success indicates the presence of something out of the ordinary in a given hex.
A Bogey counter is placed in the hex.  In some scenarios, false Bogeys may be
allowed (a Lock-On will determine them to be natural material or some form of
countermeasures).

Outstanding Success: 
An Outstanding Success on a Bogey detection roll allows the sensing ship to ask 
what the size class of the target is +-1 size class (Note that until this 
happens, or a Lock-On is made, the size of the target remains unknown).

Note:  A successful (or outstanding) Evasion attempt allows the target to apply 
what would have been its DiffMod due to evasion to the size class uncertainty

(eg; a target that has outstanding success and applied 4 g-turns, but was still 
Outstandingly detected as a Bogey would be able to exaggerate its size by 3 
sizes (+1 is normal, +2 for evasion). Note that while evasion doesn't help to
defeat Bogey Detection, it can make the target's size hard to nail down.


Sensors:
========

I have a few changes.

1.  I assume that a folding array PEMS has as many fixed elements as it can, 
therefore a ship that can support a Short Range (SR) 3 PEMS fixed array, but 
actually mounts a SR 6 PEMS could operate the 6 hex PEMS with a SR=3 even when 
the array was folded.

2.  Any active sensor may be used at a lower power to produce a lower SR. Thus,
a 16 hex AEMS could operate at SR=1 if it wished.  Also, a ship may decide to
limit sensor sweeps to 60 degree arcs if it wishes (add sensor chits to the 
heading chart, and put them in the arcs to be scanned if limited areas are to be
searched).

3.  Passive sensors receiving active signals:  a passive sensor differs from an 
active only in that it cannot broadcast.  The signal received by such a passive 
sensor when its source is active is actually stronger than the signal received 
by the active sensors' own antennas (the path length is half, and it isn't 
scattered by the target (it *is* the target :-).  

As a result, when a target goes active the passive ships get an auto BD, and get
to roll their Lock-On attempts using the range breaks for the active sensor they
are detecting (and if the active ship is unaware of them, they may do this out 
to extreme x 2).

Use the same DMs for TL difference as are used for jamming tasks in addition to 
any others.  Also, PEMS sensors can detect radar and AEMS, but not ladar. HRTs 
don't pick up AEMS sensors using these rules.

Surprise:
=========

When a target is locked, and it has no idea that the enemy is around (or doesn't
care), it may be fired on with a modified range table.  The range DMs for firing
in BL assume that the target is trying to avoid getting hit (Challenge71). It 
does this by expending a fractional amount of g-turns every turn it is in combat
(combat being as soon as they get a BD).  While these are small amounts of fuel,
they would become significant over the course of a patrol (they're 1/10 g-turn 
of fuel per turn).  Some ships might choose to "waste" this fuel before they get
a BD in which case they may not be victims of these surprise rules even if 
unaware of their hunters.  If it is not avoiding, there is little uncertainty in
its future position.  As a result, do not use the given range table.  I have 2 
modifications, use one.  1) ignore range DMs altogether, or 2) add a DM of +1
for every 10 hexes.  Any ship out of fuel, or with no maneuver drive functional 
may be fired on this way at any time (optionally, a ship might decide to 
conserve the 1/10 g-turn, and be a sitting duck).

Ships may be fired on past 44 hexes (indeed, they may be fired on out to 128 
hexes).  You may have to calculate a DV/Pen for a weapon beyond its extreme 
range.

Comments:

Patrol ships *listen*, they quietly peer into the darkness.   They wish they 
could just crank up the 480,000km AEMS array, but going active in an unknown 
area invites death--the first indication of an enemy might actually be the 
brilliant lances out of the black that kill you.  The game of cat and mouse
is 
afoot!

(pardon my ad copy writing style, but I couldn't resist :)

FIMissiles (anti radiation) will get kinda nasty, as well :)

On to the facing rules:

Facing:
=======

The facing rules allow for some odd problems. For example, a ship with a spinal 
mount could be drifting on a parallel course to a target, free to choose its 
facing for the whole turn, and still not be able to point at the target! The 
rules must be modified to change this.

The basic rules for determining facing are unchanged. Within these, however a
new type of Facing activity needs to be defined, it is called Tracking.


Tracking:
=========

A ship may allocate g-turns to point at a target, this is called Tracking the
target. It is useful for spinal mounts, or any other weapons with limited arcs 
of fire, as well as for pointing hot engines away from an enemy sensor array.

Procedure:
1. Use the rules for determining base facing to arrive at the base facing.

2. Allocate g-turns to Tracking. Select firing arc that will Track target (1, 2,
3, 4, 5).

3. Resolve Evasion tasks, if a random facing is the result, no tracking is 
possible and any g-turns expended on tracking  are lost---if an Outstanding 
success is the result, or no Evasion was attempted, go on to step 4.

4. Roll for Tracking as a Formidable task before the Sensor Lock Phase of the
turn (a Lock-On on the previous turn is required), -1 DiffMod for each g-turn
expended on Tracking. +X DiffMods for evasion (number depending on success 
level (this isn't all that clear.. this is for the *target's* evasion).

Effects of a successful Tracking task:
A ship which succeeds in Tracking a target may treat the target as if it were in
the selected arc of fire for the entire turn as long as the target stays within 
the Tracking Arc for the entire turn. An outstanding success allows +1 Arc of
fire to be added to the Tracking Arc.

The Tracking Arc of the weapon is its basic arc of fire, +1 Arc of fire for each
g-turn spent on Tracking.

For example: a ship has a facing of 6, and is Tracking with its Spinal Mount.

This ship, having spent 2 g-turns on Tracking  requires a Average Task roll to
succeed. It does succeed, and may therefore track a target that remains in arcs 
1 through 3 (the Tracking Arc) during the turn.


Effects of Facing on Sensors:
The -3 DiffMod for being in the stern arc of a target that is using g-turns 
still applies, but the sensing ship must only cross the stern arc at some point 
during the turn (the segmented movement system for missile interception may have
to be used in this case). If the sensing ship is in the stern arc for the entire
turn, it receives a -4 DiffMod.

Optional: Some ships may be listed as having a different size class when looked 
at from different angles---if so, the DiffMods will be listed in terms of the
arc in question (usually bow-on, and stern-on).
	
Eg: A Destroyer is a Needle AF, and is 1000Tons. It would be called size class 
M---but for this particular ship, it is treated as size S when viewed Bow or 
Stern On. It would be listed: Bow/Stern-On +1 DiffMod .

Effects of Facing on Combat:
Facing effects combat in much the same way it does sensors. A ship may fire at 
another with no penalty as long as the target remains within the arc of the 
weapon for the entire turn.

If the target is only in the weapon's arc for a fraction of the turn, it may 
still fire, but at +1 DiffMod.


Range:
======
The question of range is perhaps the most challenging.  If two ships are 
closing, there is a point at which the initial and final ranges can be very 
similar, but the ships may have passed through the same hex at some point in
the turn.

There are a few ways out of this. One is to use the Proportional Movement Guide 
at all times, and allow fire at each segment (in which case all the to-hit 
probabilities need to be changed since they assume 10 shots fired per turn). 
Another is to take the average distance between the 2 ships---this has some 
promise.  We have decided that because the rules were written to sample range
data once per turn, and so were the facing, and firing rules, we would allow the
turns best range to be used (except for missiles, which might not get a chance 
at a better range after they blow up). At most times (notably with military 
ships with MFDs) this will make little or no difference, as range bands for 
weapons/sensors are quite coarse.

Note that the first hex moved into during a turn is the first position of the
object for that turn.


Misc:

We use a 60x80 hex playing area, and it still isn't always big enough.  I you
decide to use a smaller board, you can always use the sensor rule additions as a
guide for setting up the scenario that starts at a closer range.

Merrick Burkhardt 	 		Ants Inc. - engaging natural history-
email: merrick@rt66.com        		"Lifting things 20 times our weight
phone: (505) 255-0653 (home)		 for almost 3 years now..."
phone: (505) 842-8409 (Ants)

------------------------------

Date: Sun, 4 Dec 1994 13:30:14 -0800
From: "Kelly St.Clair" <kstclair@CSOS.ORST.EDU>
To: traveller@MPGN.COM
Subject: Re: Serendip Belt Forever!
Message-ID: <199412042130.NAA04649@CSOS.ORST.EDU>

>Thanks, Ken. Actually, I thought we got along very well. We didn't like
>each other and we wanted the same bit of real estate, but we understood
>one another perfectly ;-). I enjoyed writing propaganda against you.

I might have gotten along somewhat better with Neubayern if I knew Ken
  was a fellow anime fan. *smile*  

>Steve will tell you that I nearly blew a gasket when I heard about how
>my successor screwed things up. Mind you, from what I've heard since
>about the Alliance and their research programs I think I would eventually
>have come a cropper myself. But I wouldn't have dragged a couple of
>billion people in with me! 

Hans speaks for me as well.  My TCS persona was Gabrielle Butler, the 
  first and apparently most moderate representative for the Belt.  While
  what the last player did isn't entirely out-of-character for the Belt
  (given what they did when they first got Jump drive from a misjumped
  Imperial:  try to take over the rest of the Islands), it still made
  me wince.  What possible motive could they have had for genocide of
  the Orpheides? 

I guess living in asteroid habitats all the time makes one a little 
  'funny'... 

---------------------------
Kelly St.Clair
kstclair@kira.csos.orst.edu 

------------------------------

Date: Sun,  4 Dec 1994 17:23:37 GMT
From: wildcat.mail.room@jaguar.ac.edu (Wildcat Mail Room)
To: traveller@MPGN.COM
Subject: Unknown address
Message-ID: <9412041800151087@jaguar.ac.edu>

The user this message was addressed to does not exist at this site.  Please
verify the name and domain in the original message that follows.

                     ----- Original Message follows -----

Date: Sun, 4 Dec 1994 12:23:37 -0500
From: traveller@MPGN.COM
To: Multiple recipients of list <MPGN.COM!traveller>
Subject: TRAVELLER digest 121

                            TRAVELLER Digest 121

     ===== edited out =====

------------------------------

Date: 05 Dec 1994 04:23:34 GMT
From: Rob_Prior@nynet.nybe.north-york.on.ca (Rob Prior)
To: traveller@MPGN.COM
Subject: Mapping Software Update
Message-ID: <1731198942.22289527@nynet.nynet.nybe.north-york.on.ca>

So far version 0.9 of Metator has the following capabilities:

- Handles entire sector (subject to memory of your computer).
- Displays sector dot-map or subsector hex maps in colour and black & white.
- Can export sector to TEXT file.
- Can generate systems on a sector, subsector, or individual basis.
- Can 'Collapse' systems on a sector, subsector, or individual basis.
- Allows editing of all system characteristics.  


Not supported yet, but on my 'to do' list:

- Extended system generation.
- Name generation (using the old MegaTraveller word generation systems).
- Importing TXT sector files.
- Exporting PICT maps of sector and subsectors.
- Printing.


Not supported yet, but on my 'to do when I learn how' list:

- Cut & paste, including conversion to text for inclusion in Scrapbook.
- Resizable, scrolling window for monitors smaller than 13".


Requested, but not yet planned:

- User-definable comments on worlds.
- Additional characteristics for starports.


Please send me any suggestions for additional features or capabilities.

------------------------------

Date: Sun, 4 Dec 1994 21:42:26 -0800 (PST)
From: Michael Llaneza <mllaneza@mercury.sfsu.edu>
To: traveller@MPGN.COM
Subject: Re: TRAVELLER digest 121
Message-ID: <Pine.3.89.9412042144.A19180-0100000@mercury>

Admin please note: there is a bounce on the list that is causing digests 
to double up. The address is wildcat.mail.room@jaguar.ac.edu which seems 
to have a bad address on its list and is returning the whole digest as 
undeliverable.

Michael Carter Llaneza
Conceptual Design Services             The Worse it gets,
Pi Kappa Phi                           The more I get used to it.
"I am the NRA"			       Duty Now For The Future


------------------------------

End of TRAVELLER Digest 122
***************************
